1. Field of the Invention
The present invention generally relates to an IP network, and particularly relates to a Quality-of-Service (QoS) controller, a method of controlling QoS, a router, and a QoS control system in an IP (Internet Protocol) network.
2. Description of the Related Art
With network speed increasing in recent years, a demand on the Internet for transferring with high quality such continuous media as voice and video is rapidly increasing. However, as major services provided via the Internet today are of best-effort type, transferring with such high quality as described above may not necessarily be guaranteed for multimedia information having a real-time property (or real-time application).
Thus, for providing a service according to the type of data flowing over the Internet, DiffServ (Differential Services) is known as a technology for providing quality of network service, or QoS (Quality-of-Service) (for example, as described in the Non-Patent Document 1). DiffServ, a technology in which a router performs priority control of traffic based on the quality class of packets, by having to identify a class identifier written in the header of each IP packet, enables priority control according to class.
In this DiffServ, for example, in case of an IPv4 header, 8 bits of the TOS (Type-Of-Service) field are used to divide traffic into a number of classes, so as to perform QoS control per class. Furthermore, in a case of IPv6, 8 bits of the Traffic Class field are used.
On the other hand, routing control is dependent upon a routing protocol such as OSPF (Open Shortest Path First) and the like. The OSPF (for example, referring to the Non-Patent document 2), referred to as a link-state type routing protocol, has associated routers prepare an information element called “a link state” so as to be delivered using IP multicast to all other OSPF routers. The router, upon receiving such a link state, based on the link-state information, prepares a LSDB (Link-State DataBase) indicating where other routers exist and how they are connected, so as to have a grasp of network topology. Thus, the OSPF, as a link-state type protocol, enables the router to have a grasp of network configuration within an area, so as to compute the shortest route.
Also, as a method of routing control for implementing the QoS, there is a multi-path routing method in which, with an objective of transferring traffic according to class, multiple routes (multi-paths) are used according to the class. For example, TOS routing, which refers to the values in the TOS field as well as to the point of destination, is described in a previous OSPF (referring to the Non-Patent Document 3); however, it is omitted at the present.
Non-Patent Document 1
(RFC 2475) “An Architecture for Differential Services”, http://www.ietf.org/rfc/rfc2475.txt
Non-Patent Document 2
(RFC 2328) “OSPF Version 2”, http://www.ietf.org/rfc/rfc2328. txt
Non-Patent Document 3
(RFC 1583) “OSPF Version 2”, http://www.ietf.org/rfc/rfc1583. txt
As described above, as a technology for providing QoS according to requirements for quality of service, there exists technologies such as DiffServ for implementing bandwidth control for QoS by a control such as queuing, scheduling, and the like by a router (related art “a”), and a multi-path routing technology for using multiple routes according to class so as to implement QoS according to class (related art “b”).
Up to now, the method of using an IP-header field according to the router control of the related art “a” and the method of using an IP-header field according to the multi-path routing of the related art “b” have been considered independently. When the related art “a” and the related art “b” are combined so as to be used, there is a portion within the IP-header field in which bit positions referred to by the respective methods as described above overlap so as to interfere with each other.
A problem arises such that when bits in a field within an IP-header, referred to by the respective methods, mutually interfere, the correlation between a router-control class and a multi-path routing class may not be changed freely. For example, when traffic is divided according to class, there may not necessarily be a one-to-one relationship between the router control class and the multi-path routing class. In other words, it is quite possible that multiple router-control classes are carried as one multi-path routing class, or even that one router-control class is divided into multiple multi-path routing classes so as to be carried as the multiple routing classes.
Furthermore, when a router-control class causes a change of transfer route, if a desired route exists at another multi-path routing class, it is preferable to change only the corresponding relationship to such multi-path routing class.
Thus when the bits referred to by the router control and the bits referred to by multi-path routing within an IP-header field interfere with each other, such mutual interfering between the router-control and multi-path routing classes makes it difficult to have flexibility in the relationship between the classes.
FIG. 14 is a diagram for illustrating such problems as described above using both the router control according to the related art “a” and the multi-path routing according to the related art “b”. In FIG. 14, routers configuring an IP network are represented as letters R1 through R4.
When combining DiffServ and TOS routing as in FIG. 14, in the DiffServ the first six bits of Type of Service field (TOS) are used as DSCP (DiffServ Code Point) (referring to FIG. 15A), while in the TOS routing the fourth through the seventh bits of the TOS field of an IPv4 header are used on a fixed basis (referring to FIG. 15B). For example, when bit sequence within the TOS field of the Ipv4 header is “00111100”, the 6 bits of “001111” represent a class of the DiffServ, while the 4 bits of “1110” represent a class of the TOS routing. In other words, the bit positions for the class of the DiffServ and bit positions for the class of the TOS routing have partially overlapping portions as represented by the fourth through the sixth bits.
Returning to FIG. 14, as in a first case, when a class represented as “001111** (DSCP)” of the DiffServ is transferred via a default route, it can be dealt with by a default route entry, but in a case where the transfer is made via a route other than the default route, it becomes necessary for the TOS routing to separately enter in a table the route represented as “***1110*”.
Furthermore, as in a second case of FIG. 14, even when trying to transfer a class of “111110** (DSCP)” of the DiffServ via the same route as “***1110*” of the TOS routing, a separate entry of “***1100” of the TOS routing is needed, requiring an independent calculation. In other words, even when passing through the same route a TOS class is required per DSCP.
Furthermore, the DiffServ class is not able to set the corresponding TOS-routing class to be changed. For example, as in a third case of FIG. 14, even if an attempt is made to send DSCP:001111 via a TOS:1000 route, a TOS:1110 route must be recalculated.
Thus, with the TOS routing and the DiffServ, as the bits referred to by the respective methods end up interfering with each other, changing a relationship between a DSCP and a routing class requires the DSCP value and the routing class value themselves to be changed. In other words, the DiffServ class and the TOS-routing class are not enabled to freely change the respective bits as described above.
Furthermore, for a DSCP to change route, there is no other way but to adjust the corresponding TOS cost (mainly determined by the bandwidth of the interface) so as to, by recalculation, change the route, resulting in a transitional burden on a router and a link.
Furthermore, even when multiple DSCP's pass through one route, if the respective TOS parts differ, as the same table cannot be referred to for the TOS routing, multiple entries must be stored for the one route as described above.
As these problems as described above occur not only in the case of the TOS routing, but also in other multi-path routing cases, combining the router control and the router routing so as to implement the QoS becomes difficult.